What do you think about having this authenticator avoid the individual service_id pattern (as we do with authn-gcp). It doesn't seem like there will be any specific details that will necessitate having multiple "versions" of the single-use token authentication workflows.

The pattern we use in the GCP authenticator is to nest the key bits under the authenticator level:

- !policy
  id: conjur
  body: 
  - !policy:
    id: authn-sut
    body:
    - !webservice

    - !group 
      id: authenticatable
      annotations:
        description: Group with permission to authenticate using this authenticator

    - !permit
      role: !group authenticatable
      privilege: [ read, authenticate ]
      resource: !webservice

I have no problem with that. I'll update the doc to remove the service-id pattern.

Are there any security concerns around passing the SUT as a URL parameter?

It's not the most secure way of passing around sensitive data, which is why we're suggesting using a single-use, short-lived token instead of using the 8 minute auth token as was previously considered. This way even if it's leaked the window for exploitation is low. Currently PSM does not support POST requests so this the only way we can do it that will work for them.

Can a user have more than one SUT active at a time? (I'd say no - a user requesting a SUT should immediately expire any existing SUTs for that user.)

Should the authn-sut throttle requests over a certain rate? (Maybe... need to think through if having a lot of SUTs active at once would be additionally problematic...)

I'm thinking about taking a page from OIDC to add security here. What if PSM (or any client) had to generate a unique code and passed the hash of that code to the authn-sut/login endpoint. Then, PSM sends the actual code to Conjur UI. Conjur UI includes that along with the SUT to Conjur. Conjur applies the same hash (we'd have to pick a single algorithm - maybe SHA256) to the code and only honors the SUT if that matches the request code.

Filling this out more explicitly - I'm modeling this on PKCE in OIDC.

1. PSM generates a GUID for a specific single use token request.
2. PSM SHA256 hashes the GUID and sends the resulting hash value and the transformation method (currently only "sha256" supported, but this will make it easier for us to introduce post-quantum crypto handling or other algorithmss later) to the endpoint for the SUT.
3. The single use endpoint includes the received hash value and transformation methods as additional columns in the database where the token is stored. The token is returned to PSM.
4. PSM sends the token and the original (unhashed) GUID to Conjur UI / Conjur. The verification process includes a step that takes the GUID, applies the transformation method associated with the token, and verifies that it gets the same result as was written from the original request. If it does not get the same result, the token is rejected and declared invalid immediately.

Key pieces:

• The GUID itself is never sent anywhere until it's used with the token to prevent interception.
• The GUID ties a single use token to a particular request, so the token can't be used elsewhere.
• The transformation method must be one way, so even if someone got a hold of the database, they couldn't reverse engineer the GUID and gain access to using the token.
• Even though we only support one transformation method at the start, we have the mechanism in place to allow other choices in the future to make upgrades and introducting new functionality easier.

Do we want to have registered client IDs and require the client to sign this request? We'd have to have a keypair set up to allow the client to request a SUT as part of the configuration, but it would stop the endpoint being used by non-authorized services.

Absolutely. We can use Cron as it's already present in Conjur and Conjur Enterprise.

@jvanderhoof Where is Cron used in Conjur? I'm not seeing it in this repository and if we need to add it that'll require some more story points in the work estimate.

My mistake. Cron is part of Conjur Enterprise, not Conjur. Two options that come to mind are:

• Remove expired single-use tokens during creation, exchange, or both.
• Create a service like the variable rotation service to run and periodically remove expired tokens

OK got it. For now I'll update this doc to allow for some extra points for figuring that out during the implementation.

@szh nice list of test scenarios. I had a couple comments/questions..

1. what if ldap is enabled for Conjur-UI login by default (same for authn-oidc but this is probably fine as local auth is allowed vs ldap)?
2. check that tokens are not logged (even though they are short lived)
3. how about authn-temp as credential name?
4. will there be a status endpoint for authn_sut?
5. could you define more than one authn_sut authenticator?

I'll clarify these. I think authn-temp is too vague - it makes it sound like the authenticator itself is temporary.

I'm actually not sure about authn-ldap - I'll need some clarification from someone more familiar with UI project.

Minor nit: PSM isn't generating the SUT. Conjur generates the SUT and passes it back to PSM.

I might make this error message something like "Invalid code verifier". No need to disclose anything that could be construed as the verification method necessarily.

I wonder if this should be only a debug message. This might be an indicator of an active attack and thus something we should be surfacing to the audit DB and maybe even at a Warning log level.

In the spirit of Jason's desire to minimize cucumber tests stated above, do we need all these Sad path tests here as well as in unit tests? 1 happy path test (generate the SUT and authenticate) and 1 sad path test to make sure errors make it to where they should be seem like enough given the set of unit tests.